tabularasafandomcom-20200215-history
Talk:Logos list
Wow, this is great. Well done! I'll try and assist with adding template information to some of the logos articles as I have time. Squeg 01:47, 9 November 2007 (UTC) These I have a logos called These, and I dont know where I got it. But, it isnt on this list. Khajja New Logos at former location of 'Future' As of 21:54 MST Nov 15 2007, the Future Logos IS NOT at the listed location is the Concordia Palisades. That logos shrine is still active, but it now contains the 'Through' Logos. Although I just grabbed this Logos, I'd appreciate another player confirming this. As a side note, does anyone know the new location for the 'Future' Logos? It's the last one I need for the Palisades.... ^-"-^ ApophisTheCursed 04:58, 16 November 2007 (UTC) Size The inclusion sizes are a bit too high for comfort. I'm pondering to trim it. First is to remove stuff that's not actually used on include. , default values, wrapping etc for preview still count towards pre-expand size, which is our biggest value right now. Also considering removing the special-casing for damage. Beyond just stating it can be found in Bootcamp (which can be done in text), there's no use in listing it here or anywhere else, much less with detailed location and verification. Either you skip bootcamp, in which case you don't need it, or you don't skip bootcamp, in which case you're being railroaded to it. - Dashiva 13:55, 7 December 2007 (UTC) : Ok, I agree to remove second shrine support which should save around 450bytes in and and around 1050bytes in . Only is used on the Logos list though. But I don't want to remove second gate support, until we find a better way how to solve it. Without the second gate, the Logos list will contain incomplete information. : BTW: I try to create DPL version of Logos list - it shouldn't be complicated, when we agree to have only one shrine location per Logos symbol and update all Logos articles to use template. (already done for Concordia Logos, otherwise they couldn't be used for Logos Map and Wilderness automatic Logos list on the Zone page. :→ Zarevak 10:22, 9 December 2007 (UTC) :: Yeah, gates are kinda tricky. I haven't thought of a good solution yet, so I'll leave it be. It would also be useful to see if there are more cases of double gates, which would affect the decision. As for DPL it looks very promising. I was thinking we could switch once the category restructuring is complete. The current page is more resistant to random changes there. :-) - Dashiva 17:23, 9 December 2007 (UTC) :: Done some trimming, and hopefully fixed all the breakage it caused. - Dashiva 14:23, 12 December 2007 (UTC) ::: Good work; only one more slight problem had to fixed I'm thinking about merging the Logos list/T/Item/table into Logos list/T/Item as we don't have any more styles available (it was created with an idea to have different style for inclusion to Zone articles). Some of the Zone articles are already using DPL based Logos list (Wilderness, Pools, ...) and doesn't need anything from Logos list. If the Logos articles stays updated the Zone Logos lists are updated automatically without any problems and support for different Logos list styles is not needed. ::: → Zarevak 22:46, 12 December 2007 (UTC) :::: I was thinking the same, but left it alone since I didn't know if you had any other plans for the syntax. Maybe we've reached a point where it would be smart to draw up all the current logos uses and inclusions and figure out which parts we're actually using and which are going to be replaced (e.g. by DPL). Possibilities that come to mind: replacing the entire logos list set with DPL; this might remove the need for the double-included template in logos articles. I might be wrong, these are just some examples. - Dashiva 22:27, 13 December 2007 (UTC) ::::: I've made a hasty assessment, because the Logos list/T/Item template is helper template which includes the Logos article with parameter Logos list/T/Item/table. The Logos are used on these pages: :::::* Logos list - I prefer static lists as it is easier for the visitors to move/add/remove Logos from Zones :::::* Zone articles (Wilderness uses DPL, Palisades uses Logos list) - I prefer DPL here :::::* Other Logos articles - listing Logos needed for opening the Logos gates - static link :::::* Abilities articles and their Logos requirements - static link :::::* Targets of Opportunity and Mentalist title - ??? Yesterday I was able to get Wilderness Mentalist title for just Logos in the Wilderness battlefield without going to any instances :::::* Mission articles and their requirements and rewards - static link :::::* Logos articles lists Abilities they are required for. The list is now static, but it's outdated after the 1.3.2.1 Patch. I would prefer using DPL here, but it won't work for Power (Bootcamp) (logos). :::::*: This would also largely shorten the Templates, because we wouldn't need to use lists of 25 possible abilities ::::: ASCII Map of the Logos include system: Logos list | 1..N | +--Logos list/Zone -- this is Logos list for one Zone and its Instances | 0..N | +--Logos list/T/Item -- this is helper template deciding if we can use Logos article as data source | | | 0..1 (if Logos (logos) exists) | | | +--Logos (logos)|Logos list/T/Item/table | | | 1 | | | +--Template:Logos|Output=Logos list/T/Item/table|... | | 1..0 (else) 1 | | | +--Logos list/T/Item/table|... -- this creates output for known Logos | +--Logos list/T/Item/table|Name=Logos -- this creates output for unknown Logos Logos (logos) | 1 | +--Template:Logos|Output=Template:LogosArticle|... | 1 | +--Template:LogosArticle|... -- this creates basic Logos article structure | | +--1--Template:LogosInfoBox|... -- this creates Logos infobox | | +--1--Template:LogosShrineLoc|... -- this creates Logos Shrine Location table Legend: ... = more parameters - especially Logos data (name, location, list of abilities, ....) 1 = exactly one inclusion 1..N = one or more inclusions 0..N = zero, one or more inclusions 0..1 = zero or one inclusion - decided by #ifexist|... 1..0 = zero or one inclusion - else part of 0..1 ::::: → Zarevak 16:48, 14 December 2007 (UTC) :::::: Comments to the above: ::::::* I see no problem using DPL for abilities, we could just put up a notice on the bootcamp version of Power that it's a placeholder article, and one should see the main Power article for complete information. That we keep the article is not a given anyhow, I only created it because it was the easiest way to remove the parameter dependency. ::::::* In general I support DPL for simple lists (like zone logos listing) and for standalone complex listings (like your personal toybox), but I oppose it for complex usage in normal articles. Or in other words, we should not hide formatting and other details inside DPL in normal articles, as they should be editable by normal people. ::::::* The above does not affect any current usage, I agree with your assessment on when to use static links and when to use DPL. :::::: Further evaluation: ::::::* I see no big benefit in keeping LogosShrineLoc and LogosInfobox templates around. They could be put into LogosArticle and save us a bunch of complexity. Also helps make the logos template set easier to understand. ::::::* I recall we are using Template:Logos and double inclusion for some reason, but I am unable to recall it. This refers to using } instead of } in the main logos articles. :::::: - Dashiva 13:53, 25 December 2007 (UTC) ::::::: Comments to the above: :::::::# As you suggested in your earlier comments, we can remove the whole Power in Bootcamp article. All the players will be lead to it by mission objective or they will skip the Bootcamp and look for the real Power logos shrine. :::::::# The 1.6.3 version of DPL supports easy table generation or we could use template substitution to create the desired output. But for now I don't see any good usage for such features - we mainly want to create small lists and Logos list will stay static. :::::::# The Targets of Opportunity mission Logos list should IMHO be static as well, because there are some problems with the lists (like Palisades ToO requiring Future (logos) in previous patches) and we won't be able to fix this on DPL level. :::::::# No problem in merging and to . :::::::# DPL (at least in current 1.2.1 version) AFAIK cannot extract template parameters from unnamed templates: }. To support DPL we have to use: }. I welcome any idea how to solve this issue, because just passes parameters to other templates... ::::::: → Zarevak 16:51, 25 December 2007 (UTC) :::::::: Ah, so that's the reason. Will probably do some tests once we get the new DPL, but all the work is already done so it's not a big deal if we keep it around for longer. - Dashiva 19:34, 25 December 2007 (UTC) Progress * Merged LogosShrineLoc and LogosInfobox into LogosArticle, and marked for deletion. * Not done any other changes to LogosArticle or Logos yet. * Simplified Logos list/T/Item to assume article existence. If a logos is being added, creating the article should take precedence anyhow. * Moved Logos list/T/Item/table to Template:LogosRow to match LogosArticle, and make for more sensible inclusion lines. * Marked a few other Logos list templates for deletion, being unused and simple enough to do without templates if needed. * Went through all Logos lists and removed style parameters. To follow the previous diagram, it now looks about like... Logos list/T/Item -- this is a helper template | +--Logos (logos)|LogosRow | +--Template:Logos|Output=LogosRow|... | +--Template:LogosRow|... -- this creates brief Logos entry as table row Logos (logos) | +--Template:Logos|Output=LogosArticle|... | +--Template:LogosArticle|... -- this creates basic Logos article structure Moving ahead: * Consider using LogosRow and feeding it into DPL for a standardized representation. This would allow more complex DPL displays while still keeping the formatting in "simple", centralized wikitext. * Maybe also create a LogosListItem or similar for an even briefer list entry (e.g. like used in zone articles) * Still need to research Template:Logos and DPL interaction when we get mw 1.12. * I found a few logos pages that don't use the DPL-friendly format, might be more out there. * Still need to weed out all the |param= } in logos pages (but harmless for now, so very low priority). I'm also starting to think about the TaRapedia:Logos Reference. After we removed logosref it's basically just a list of all the logos icons in the game files. I don't see a reason for it to remain outside user space. And that's it for now. - Dashiva 02:00, 3 January 2008 (UTC) : Great work on merging the templates! I've tried to delete ( ) and ( ) but found out it is still used on the old Logos articles. I'm thinking about deleting the articles because they don't contain any useful information other then the icon. What do you think? : → Zarevak 13:21, 6 January 2008 (UTC) :: No objections from me for deleting. In addition to the templates, they also clutter DPL searches for %_(logos). I believe they are the last dependencies on Logosref as well. - Dashiva (talk) 13:46, 6 January 2008 (UTC) :: To poke a little more at our logos inclusion/dpl/substitution mess... we have three different use cases. ::* The main article ::* External use via inclusion (logos list) ::* External use via DPL (battlefield) :: The information must reside in the main article, so the first requirement means the article must include a template which either is LogosArticle, or in turn includes LogosArticle (e.g. Logos). The second requirement means the inclusion must at one stage be parameter-based with LogosArticle as the default parameter value. And the third means the inclusion must at one stage have a static name to hook into. :: We will attempt to avoid the third condition. Now, the DPL substitution is simple string matching, so matching a complex template name is not a problem. We can almost match }|...}} and turn it into }|...}}, but the regular expression splitting later ruins it. We have to supply \{ and \| for the splitter to work, which leads to attempting the include }|...}}. This obviously does not work. However, the up-to-date DPL does quote this parameter, so as far as I can see this should work in the future. includepage = - Dashiva (talk) 23:55, 6 January 2008 (UTC) Update classification I cleared out the last 'beta' class logos in Mires a while ago, so there's no reason to keep that classification around anymore. I removed it and added a new class 'recent' between 'old' and 'live'. 'recent' means the logos was updated less than 30 days before the most recent patch. Going by monthly updates, this is a rough approximation of "updated during the previous patch". The intent is to have a class for "not updated in this patch, but not old enough that you should bother checking it again unless you happen to pass by". I'm not particularily attached to the value 30, and I could easily see it becoming larger, particularily as the game becomes more stable. I don't foresee existing logos changing much, just new ones being added. It needs a better color, though. - Dashiva (talk) 22:23, 9 February 2008 (UTC) Further updates on reorganization I have moved both the row header and the row item templates into the main template space. I plan to start using these in logos mission articles (among other things), so they have general use. I also cleaned out the templates that weren't used, and updated the ones that were. I also cleaned out LogosArticle's old pals logosShrineLoc and LogosInfoBox after setting placeholder text on all the logos articles for logos that don't exist (Category:Logos that do not exist). There should be no breakage, but as always, stay alert. - Dashiva (talk) 22:31, 17 February 2008 (UTC) To expand on the LogosRow usage, the example is at Logos: Clarity and Death. It lets us give direct access to the logos data, with an edit link, and standard presentation. This cuts down on redundancy, and makes it easier to update things. It also provides a very basic walkthrough for the walkthrough section. :) However, as you will notice by following the link, LogosRow does not currently include the planet/continent/zone info, only instance if applicable. I would propose we modify this so it states the instance if valid, and zone if not. (Or perhaps zone+instance, and only zone.) The header would be changed as well. Thoughts? - Dashiva (talk) 22:44, 17 February 2008 (UTC)